home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000169_news@columbia.edu _Fri Dec 29 21:42:38 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA14352
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 21:42:38 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA05809
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 21:42:36 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id VAA28021
  10.     for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 21:24:43 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: r@your_host.com (cLIeNUX user)
  13. Subject: Re: Converting struct tm to time_t
  14. Date: Sat, 30 Dec 2000 02:23:17 -0000
  15. Organization: Posted via Supernews, http://www.supernews.com
  16. Message-ID: <t4qholhk7rbt30@corp.supernews.com>
  17. To: kermit.misc@columbia.edu
  18.  
  19. fdc@watsun.cc.columbia.edu... 
  20. >In article <92i02v$m4u$1@news01.si.uniovi.es>,
  21. >Igor Sobrado  <sobrado@string1.ciencias.uniovi.es> wrote:
  22. >: Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  23. >: > In article <3A4BA47C.53C64EBA@srv.net>, Kevin Handy  <kth@srv.net> wrote:
  24. >: > : Frank da Cruz wrote (about mktime()):
  25. >: >
  26. >: > 2. Doesn't do what you want.  "In addition to computing the calendar 
  27. >: >    time, mktime() normalizes the supplied tm structure" -- applies
  28. >: >    timezone conversions, etc.  The problem there is, of course, we
  29. >: >    don't know, and have no way to find out, the server's timezone, and
  30. >: >    even if we knew it, what the rules are to convert to our own.  The
  31. >: >    struct tm is *already* in GMT/UTC, and should not be converted to
  32. >: >    it again.
  33. >: >
  34. >: > Thus the resulting file date won't be what you want.  I think the
  35. >: > object of copying the server's MDTM is so update can work in both
  36. >: > directions.  If we use mktime(), I think the result will have up to 24
  37. >: > hours of randomness added or subtracted.  Am I missing something?
  38. >: 
  39. >: As you noted, the FTP-server provides the time in UTC/GMT, all
  40. >: Unix boxes work with that standard convention. The second (incorrect)
  41. >: conversion to UTC is made locally by the host where C-Kermit
  42. >: is installed because mktime(3C) supposes that the tm structure is
  43. >: in local format, not it UTC. Why not calculate the UTC offset for
  44. >: the time (as if it is in local format) and "correct" the time
  45. >: either before converting it to a time_t structure or after that?
  46. >: 
  47. >This leads only to more difficulties.  The time-related APIs are the most
  48. >twisted and crazed ones in UNIX, and vary significantly from platform to
  49. >platform and version to version of the OS, C library, and compiler and
  50. >header files.  How do you find out the timezone or GMT/UTC offset?  Is it
  51. >an API call (gettimeofday() or what?), a global long, ulong, int, short,
  52. >etc?  A global struct timezone?  And/or is it extern time_t tzoffset?  A
  53. >member of struct tm?  Obtained how?  And what are the units?  And can you
  54. >believe them?  Do they or do they not account for daylight savings time?
  55. >If not, how do we compensate?  Here's a typical man page quote:
  56. >
  57. >     The external long variable timezone contains the difference,
  58. >     in  seconds,  between  GMT  and local standard time (in PST,
  59. >     timezone is 8*60*60).  If this difference is not a constant,
  60. >     timezone  will contain the value of the offset on January 1,
  61. >     1970 at 00:00 GMT. Since this is not necessarily the same as
  62. >     the  value  at  some  particular  time, the time in question
  63. >     should be converted to a tm structure using localtime()  and
  64. >     the  tm_gmtoff  field of that structure should be used.  The
  65. >     external variable daylight is non-zero if and only  if  Day-
  66. >     light  Savings  Time  would  be in effect within the current
  67. >     time zone at some time; it does not  indicate  whether  Day-
  68. >     light Savings Time is currently in effect.
  69. >
  70. >This would not be encouraging even if it applied to every platform,
  71. >but it's only for one release of one OS.  In many OS's (e.g. BSDI) the
  72. >variables and structs stay the same but their meaning changes from one
  73. >release to the next.  In other OS's the structs and variables change, the
  74. >header files move, and every other manner of obstacle can be expected.
  75. >
  76. >In fact, I can try to program all this, but to make it compile, link, and
  77. >run correctly on hundreds of platforms is not going to be pleasant, as you
  78. >can already tell by looking at the other time-related code in cku[ft]io.c.
  79. >
  80. >If anybody has any helpful or simplifying suggestions, I'd be glad to
  81. >hear them.  The question is:
  82. >
  83. >  How to convert a struct tm (which already is expressed in GMT) to
  84. >  a time_t which expresses the clock time in GMT (not local time) in
  85. >  a way that is reliable (works in any timezone and takes daylight
  86. >  savings into account) and is portable to as many UNIX platforms as
  87. >  possible (and how to do the same things on the platforms to which
  88. >  this portability does not extend)?  The answer (as noted previously)
  89. >  is not mktime(), since it presumes its argument is in local time,
  90. >  not GMT.
  91. >
  92. >I'll copy this to comp.unix.programmer.
  93.  
  94.  
  95. Daylight savings is an arbitrary political phenomenon. A locale thing.
  96. Plan9 recuses itself from locale issues altogether, leaving them to the
  97. localities, with comments to the effect that no one else can cope. I don't
  98. know if Plan9 is that way about time, but it's the same issue. The
  99. individual Plan9 admins, in this case. I don't deal with the problem in my
  100. little Linux distro either. Even where the tz stuff can be found, it's
  101. horrid. I personally try to keep local non-political time on my box. And
  102. wristwatch. 
  103.  
  104. Oldtimers call what we have now "railroad time". Time used to be relative
  105. to Town Hall or the Cathedral or what-have-you. Technology should at this
  106. point allow us to move back toward that. Let the airlines and the
  107. railroads and networks deal with the diffs, not you and me. 
  108.  
  109. My-wristwatch-local time is of course a fantasy. GPS's are still a bit
  110. large for that :o) Less extreme perhaps is the idea that locale support in
  111. a systems programming language ( C ) is absurd. Plan9 mumbles something
  112. faintly derogatory about software-by-committee concerning POSIX locale
  113. stuff.
  114.  
  115. Bottom line; see what the problem looks like if you leave daylight savings
  116. to the admin.
  117.  
  118. Rick Hohensee
  119. www.clienux.com
  120.  
  121.  
  122.  
  123. >
  124. >- Frank